feat: Integrate bulk token screening into transaction simulation flow within runAfterSimulateHook #6617
+636
−7
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…taMask/core into feat/add-token-screening-tx-controller
…d TransactionController
AugmentedMode
changed the base branch from
main
to
feat/add-bulk-token-screening
…redundant logging
AugmentedMode
changed the title
AugmentedMode
changed the title
cryptotavares
requested changes
Sep 17, 2025
There was a problem hiding this comment.
There are two solutions that would not require coupling our code into the transactions controller. We can:
- just listen for transaction controller state changes within the phishing controller, and whenever there are state changes in a transaction simulation data, we fire the bulk scanning method. This should be seamless as all controllers already emit state change events.
- add the logic to the actual (afterSimulate)[https://github.com/MetaMask/metamask-extension/blob/main/app/scripts/controller-init/confirmations/transaction-controller-init.ts#L131] hook on the transaction controller initialization. The goal of the hooks architecture is for us to be able to add non transaction related logic to be run in different steps of the transaction lifecycle but at the same time keep the codebase decoupled and the domain ownership easily identified.
I would personaly go with option 1 that I highlighted above, as it allows us to adopt the solution on mobile without any changes (despite the UI ones to display the trust signals).
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
… state subscription in PhishingController
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Explanation
This PR integrates the bulk token screening functionality from the
PhishingControllerinto the TransactionController's transaction simulation workflow. When a transaction simulation completes with received tokens, those tokens are scanned in a fire and forget method.Changes introduced
#bulkScanReceivedTokensmethod that scans tokens received during transaction simulationPhishingController:bulkScanTokensto the TransactionController's allowed actions#afterSimulateworkflow as a fire and forgetScreenshot showcasing the
tokenScanCacheis implemented as expectedThis is grabbed via the extension console using await stateHooks.getPersistedState() after triggering a swap in uniswap. You will notice i was doing a swap for USDC which is the only token address stored in the cache.
References
Checklist